home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0082 / 72.txt < prev    next >
Text File  |  1997-04-16  |  12KB  |  284 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Fri, 19 Jan 90       Volume 90 : Issue   72
  4.  
  5. Today's Topics:
  6.                             ARC 6.02 bugs
  7.                          Help with Sozobon||
  8.                   IBM PC / ATARI ST Disk Screwed Up
  9.                            reserving memory
  10.                             TT availablity
  11.                            uucp on an Amiga
  12.                     WANTED: LONG. & LATITUDE DATA
  13. ----------------------------------------------------------------------
  14.  
  15. Date: 19 Jan 90 21:15:26 GMT
  16. From: shlump.nac.dec.com!engage.enet.dec.com!oldtmr!wallace@decuac.dec.com  (Ray
  17.  Wallace)
  18. Subject: ARC 6.02 bugs
  19. Message-ID: <1432@engage.enet.dec.com>
  20.  
  21. In article <1422@engage.enet.dec.com>, wallace@oldtmr.dec.com (Ray Wallace)
  22. writes:
  23. > I could not get ARC 6.02 to work with UNARC. ARC bombs everytime UNARC calls
  24. > it.
  25.  
  26. It turns out that I can not get ARC 6.02 to work with any of the graphical
  27. shells I have for ARC (ARCSHELL, ARCGSH21, UNARC). All of them produce either
  28. two or four bombs (it keeps changing) when they go to execute ARC. The older
  29. version of ARC (v5.21b I think) runs fine with all of these shells.
  30.  
  31. Has anyone else had trouble with ARC V6.02 running under these shells? I
  32. assume it is working for most people since no one else has mentioned the
  33. problem.
  34.  
  35. ---
  36. Ray Wallace
  37.                 (INTERNET,UUCP) wallace@oldtmr.enet.dec.com
  38.                 (UUCP)          ...!decwrl!oldtmr.enet!wallace
  39.                 (INTERNET)      wallace%oldtmr.enet@decwrl.dec.com
  40. ---
  41.  
  42. ------------------------------
  43.  
  44. Date: 19 Jan 90 17:58:02 GMT
  45. From: van-bc!ubc-cs!alberta!myrias!mj@ucbvax.Berkeley.EDU  (Michal Jaegermann)
  46. Subject: Help with Sozobon||
  47. Message-ID: <632771884.17691@myrias.com>
  48.  
  49. From article <0017900052080999@thelake.mn.org>, by steve@thelake.mn.org (Steve
  50.  Yelvington):
  51. > [In article <1037T6M-RIIT@FINTUVM>, T6M-RIIT@FINTUVM.BITNET writes:]
  52. >
  53. >> 3)  Well well, there is still the make utility (the doc of which I just
  54. >>     can't understand and got no UNIX manual at hand). I cook up a file
  55. >>     called MAKEFILE with
  56. >>         hello.tos: hello.o
  57. >>             cc -o hello.tos hello.o
  58. >>     in it - copied straight from a USENET news article sometime in August.
  59. >>     Wonder if there's any sense in this... well, type make.
  60. >>     "No targets provided near line 2". I take the monitor and smash it on
  61. >>     the wall and eat the ST and go hang myself.
  62. >
  63. > This, of course, is the primary purpose of make. By causing budding
  64. > programmers to smash monitors and hang themselves, the supply of
  65. > programmers is restricted, and salaries can be kept high.
  66.  
  67. In a spirit of purpouse stated so eloquently above Steve forgot to tell
  68. you one small thing. :-).  A white space between left margin and "cc"
  69. on line 2 in your makefile does not consist of blanks, but IT HAS to be
  70. a TAB character (0x09, ctrl-I).  This is a misfeature on an original
  71. Un*x make and got stumped generations of beginning C programmers.  I
  72. guess that we are doomed to live with it, like with segments on PeeCee.
  73. Otherwise your makefile is fine (it is using built-in default rules to
  74. produce .o files from your source .c).
  75.  
  76.  
  77.         Michal Jaegermann
  78.         Myrias Research Corporation
  79.         Edmonton, Alberta, CANADA
  80.         mj@myrias.COM
  81.         ...?uunet,alberta?!myrias!mj
  82.  
  83. ------------------------------
  84.  
  85. Date: 19 Jan 90 21:47:00 GMT
  86. From: shlump.nac.dec.com!carafe!goldstein@decuac.dec.com  (Fred R. Goldstein)
  87. Subject: IBM PC / ATARI ST Disk Screwed Up
  88. Message-ID: <7624@shlump.nac.dec.com>
  89.  
  90. In article <2646@cunixc.cc.columbia.edu>, ia4@cunixd.cc.columbia.edu (Imran
  91.  Anwar) writes...
  92. >...One of the staff there solved the problem by "Formatting a Low Density 3.5"
  93. >Disk on a High Density Drive" command available in the menu. Sure enough,
  94. >the floppy formatted as 720K on the 1.4M machine worked fine on the 720K drives
  95. >including my Atari ST drive.
  96. >
  97. >So I spent the whole night typing some reports and saved them on this floppy.
  98. >The next day, at school, I had to use the 1.4M drive PC as that is the one
  99. >connected to a Laserprinter. But, surprise, that very drive that had formatted
  100. >the disk showed it to be blank (even though the files showed up on the 720K
  101. >drive PCs). It simply said, File Not Found.
  102. >
  103. >What could be the problem?
  104. >...My question(s). Any idea of what could have happened? Solution?
  105.  
  106. I own both an ST and a PClone witha 1.44 drive.  Unlike the one you
  107. used, mine has no trouble at all reading/writing 720k formatted disks.
  108. Unlike 5.25" disks, there's no difference in track size between the
  109. two densities, just in track density and write current.
  110.  
  111. Probably the 1.44 drive is broken!  But the other likely problem is that
  112. you screwed up the disk by swapping IBM-formatted disks on the ST.
  113. Remember that the ST uses disk serial numbers to determine media change.
  114. MSDOS disks don't have serial numbers.  So swapping two MSDOS disks
  115. on an ST, without inserting an intermediate Atari-formatted disk, will
  116. make the ST think you've reinserted the same disk, and it'll use the
  117. old FAT info.
  118.  
  119. I format disks on the ST using IBMFMT, a freeware utility that writes
  120. MSDOS-formatted disks with the random serial number.  TOS 1.4 does the
  121. same.  Other formatters don't, and you should be careful not to confuse
  122. the ST serial number checker.
  123.        fred
  124. ---
  125. Fred R. Goldstein   goldstein@carafe.enet.dec.com
  126.                  or goldstein@delni.enet.dec.com
  127.                     voice:  +1 508 486 7388
  128.  
  129. ------------------------------
  130.  
  131. Date: 19 Jan 90 17:34:44 GMT
  132. From: voder!pyramid!athertn!alex@ucbvax.Berkeley.EDU  (Alex Leavens)
  133. Subject: reserving memory
  134. Message-ID: <16863@laurel.athertn.Atherton.COM>
  135.  
  136. Well, the first thing you don't want to do is to malloc()
  137. all of the currently available memory.  Doing this (as you've
  138. found) is a good way to cause things to lock up, because other
  139. applications (the desktop is one) need free memory, too.
  140.  
  141. In addition, when you malloc() all of free memory, you're making
  142. the assumption that you're the only process running, which
  143. may or may not be true.  What if you have desk accs running?
  144. What if you have a multi-tasking system?  You haven't left any
  145. memory for anybody else.  Not nice.
  146.  
  147. As for how much memory you _should_ reserve, this is kind of a
  148. tough question, for it depends very much upon what your application
  149. is doing.  I recently wrote a cardfile database that mallocs()
  150. memory;  in my case, I malloc() only the amount of memory that
  151. I need in order to fit that card into memory.  This has advantages
  152. and disadvantages:
  153.         1) The advantage is that I only take a little bit of memory
  154. from the system each time (I actually take a bigger chunk than just
  155. a single card, because the MWC malloc() routine carves out a medium
  156. sized chunk from GEM, and then parcels it out to me).  Thus, any
  157. other application which is running can still get memory if it needs
  158. it.
  159.         2) The disadvantage is that because I make a _lot_ of mallocs(),
  160. I have to use folder100.prg in order to increase my memory pool size,
  161. otherwise I run out.  (That's not really a big disadvantage).
  162.  
  163. In other words, it pays to behave nicely in the system, and use only
  164. those resources that you really need right now;  don't assume that
  165. you're the only application that's running, and don't assume that
  166. just because you got back NNNN bytes free from Malloc(), that you
  167. can therefor grab NNNN bytes from the system.
  168.  
  169. --
  170. |-------------------------------------------------------------------------|
  171. |--alex | alex@Atherton.COM |  Caution!  Falling Opinions, next 6 miles   |
  172. |        Now who are you gonna believe--me, or your own lyin' eyes?       |
  173. |-------------------------------------------------------------------------|
  174.  
  175. ------------------------------
  176.  
  177. Date: 19 Jan 90 22:39:06 GMT
  178. From:
  179.  cs.utexas.edu!jarvis.csri.toronto.edu!clyde.concordia.ca!sherlock!stefan@tut.ci
  180.  s.ohio-state.edu  (BUCHHOLZ)
  181. Subject: TT availablity
  182. Message-ID: <1794@clyde.concordia.ca>
  183.  
  184. In article <1990Jan17.230810.17704@Solbourne.COM>, stevem@katmandu.Solbourne.COM
  185.  (Stephen Matson) writes:
  186. >>
  187. >>
  188. >>        Later Atari, I'm not waiting around for your lies anymore.
  189. >>
  190. >>   "FRODO LIVES"                                "COLORADO!!"
  191.  
  192. >Well, good riddance to bad rubbish. Ohhhh, poor baby! He can't get
  193. >a TT... Well, frankly, I, and more than a few of us could not care
  194. >less. Apple or Amiga *deserve* someone like him. And "FRODO
  195. >LIVES"??? The rallying call for extreme nerds. I'm surprised that
  196. >anyone uses that old saw, it's about 20 years old, ne?
  197.  
  198. ...(?)
  199. >I've seen enough people cry to their mothers that Atari did/does
  200. >this, wahhhhhh! I don't wanna play anymore with them...
  201.  
  202. >Well, wake up to the real world buddy, pull your head out. Do you
  203. >think for a moment that when Apple announces, it will ship on time,
  204. >every time? Remember the announcements for the Macintosh, and
  205. >especially the much ballyhooed new type of disk drive *that did not
  206. >work*??? Millions spent on the drive, and it didn't work better
  207. >than the Sony 3.5" drive. So they made that oddity, the GCR drive,
  208. >and you get a computer that costs more, uses a totally odd drive,
  209. >than other current systems that at least have similar performance.
  210.  
  211. >Gee, grow up, and get a life...
  212.  
  213. >Mark Newton-John
  214.  
  215.         Guys, lets try to leave religion in the churches.  I really think
  216. that this OTARI-devotion is getting slightly out of hand.  This (and all)
  217. newsgroups are in place for people to share info.
  218.  
  219.         I personnaly love reading this religious stuff but there's a limit...
  220.  
  221.         As for the TT: look at the specs (whatever is out) and I think the
  222.                         availability date will be insigificant.
  223.  
  224.         Merry Xmas.
  225.  
  226.         Stefy
  227. --
  228. --
  229.    (ames att sun)!pacbell! \      Sakura-mendo, CA
  230.            ucdavis!csusac! - sactoh0!mfolivo
  231.               uunet!mmsac! /      the good guys!
  232.  
  233. ------------------------------
  234.  
  235. Date: 19 Jan 90 22:18:56 GMT
  236. From: sei!bmc@pt.cs.cmu.edu  (Brian M. Clapper)
  237. Subject: uucp on an Amiga
  238. Message-ID: <5719@dx.sei.cmu.edu>
  239.  
  240. A friend of mine owns both an Atari ST and an Amiga, and he would like to
  241. be able to talk UUCP with other machines over a modem.  Is there a utility
  242. that runs on either platform that will support such a protocol?  It doesn't
  243. have to be a public-domain program; he just wants to know if anything like
  244. this exists.  Failing that, is there a version of Unix or Xenix that will
  245. run on the Amiga?  (That's the sledgehammer solution.)
  246.  
  247. If you know of any thing that fits the bill, I'd appreciate the info.
  248. Please respond to me via electronic mail (at "bmc@sei.cmu.edu"), as I do
  249. not normally read this newsgroup.
  250.  
  251. --
  252.  
  253. Brian M. Clapper
  254. <bmc@sei.cmu.edu>
  255.  
  256. ------------------------------
  257.  
  258. Date: 19 Jan 90 12:28:07 GMT
  259. From: usc!srhqla!quad1!ttidca!woodside@apple.com  (George Woodside)
  260. Subject: WANTED: LONG. & LATITUDE DATA
  261. Message-ID: <9154@ttidca.TTI.COM>
  262.  
  263. In article <111500081@uxa.cso.uiuc.edu>, glk01126@uxa.cso.uiuc.edu writes:
  264. >       I am looking for data pertaining to the longitude and latitude of as
  265. >       many cities in the world as possible in order to write an
  266. >       astrological plotting program.  Does anyone know where I may
  267. >       find them or could someone possibly send them?
  268.  
  269. The Austin Code Works, of Austin Texas, sells code for MS-DOS systems.
  270. Their listings can be found in some MS-DOS related magazines, and, if I
  271. recall correctly, either C Programmer's Journal or Dr. Dobbs.
  272.  
  273. Among their listings are disks with geographic data bases on them.
  274.  
  275. --
  276. * George R. Woodside - Citicorp/TTI - Santa Monica, CA *
  277. * Path:       woodside@ttidca                          *
  278. *   or:       ..!?philabs|csun|psivax?!ttidca!woodside *
  279.  
  280. ------------------------------
  281.  
  282. End of INFO-ATARI16 Digest V90 Issue #72
  283. ****************************************
  284.